Summary

• Verify live IBKR order-write access with an IBKR what-if order before execution; the probe cannot execute as a live order.
• Fail closed when the selected cash-only account snapshot lacks an explicit market-currency cash balance, and recognize IBKR ledger cash tags without treating AvailableFunds as cash.
• Propagate rejected submissions as a blocked execution result through runtime reports and heartbeat validation.
• Treat pre-market timestamps outside the returned calendar schedule as market-closed so an explicit force-run can proceed safely.

Root cause

The runtime could prove API connectivity but not writable order access. It could also receive valid IBKR account data using $LEDGER-* cash tags while resolving cash to zero, and rejected submissions could be reported as a successful/no-op cycle. Separately, the market calendar raised before the force-run override was evaluated during pre-market verification.

Behavior and safety

• The permission probe uses IBKR whatIfOrder; IBKR evaluates commission and margin but does not place the order.
• Cash-only execution remains fail-closed whenever a supported market-currency cash balance is absent, including when positions exist.
• A fully rejected submission becomes execution_status=blocked; runtime reports and heartbeat checks reject it, except for the existing expected safety guards.
• The HTTP response remains 200 for a blocked cycle to avoid automatic Scheduler retries, while the durable runtime report is marked as an error.
• Transient connection failures during the permission probe retain the existing retry behavior.

Validation

• Related tests: 103 passed
• Ruff on affected Python files: passed
• Python bytecode compilation for affected runtime modules: passed
• git diff --check: passed

The repository-wide suite was not rerun after the final review fixes; prior full-suite runs contained known baseline failures outside this patch. The affected test set above was rerun from the final commit state.

Live verification scope

An earlier pre-review revision was manually deployed to the single authorized live target. /health and dry-run returned 200. One authorized live run returned 200 and submitted one DAY limit order with status Submitted; no read-only/API-321 failure was observed. This confirms submission, not fill.

The current head, including the what-if permission probe and subsequent Codex review fixes, has not been redeployed. Its evidence is the local validation and PR checks above; the normal deployment pipeline can replace the manual deployment after merge.